A continuation of my intermittent series on Emdebian and prompted by a query from Paul Wise, I thought I'd cover some of the uses to which a device running Emdebian can be put. It is a bit long this one...

So, yes, there are general purpose computers which could run Emdebian but there are common features amongst general purpose computers:

1. Lots of different tasks must be supported - lots of different packages installed, each user could quite easily use a distinct set of packages from another user.


2. Multi-user support - even if any one machine is only used by one person, a general purpose computer must have support for adding another user - not just a system user, a real user with a login, shell, possibly bookmarks and browser history etc.


3. Connectivity - general purpose computers (and that includes mobile phones) must connect to a variety of other computers to be at all useful.


4. Multi-modal data input - there needs to be support for a mouse and a keyboard or touchscreen and just as likely, software support for accessibility interfaces like an on screen keyboard and switch inputs.


5. Storage for user data - the system admin can't know how much data users are going to add and if it is general purpose, it's probably going to support media players, image viewers, even office software. The data files managed and written by such software tend to be large and tend to accumulate into large collections. This means that a general purpose machine cannot anticipate the full storage requirements, so has to allow plenty of room for user data storage. If there's so much storage space available, why use an OS which is primarily designed to take up less space? Just use the full version, Debian.

Now compare with the common features of special purpose or single-purpose computers:

1. Single task only - a splash screen (without support for removal) covers all the boot information, the single task starts as a daemon and if the user quits the task, the task initiates a shutdown, not quit. Every effort is made to prevent the task from exposing the underlying OS, including auto-restarts if it does crash.


2. Single-user support - indeed, user is not the typical user. user in this case is a non-login user without a shell, created by the postinst of the task package purely to support running the task without root privileges (because if the task doesn't need privileges, it shouldn't retain privileges).


3. Single mode input - don't expect these machines to support 105 key keyboards. You'll be lucky to have 5 keys which are really just buttons. The button won't just enter 'J' into the machine, it will fire off a command to charge your bank or start a drill or shutdown a malfunctioning service. (Each button will often be multi-functional as well, depending on context). Some devices will replace the mouse with a touchscreen but many are fitted in places where touchscreens simply won't survive, where keys have to be able to withstand being submerged in water (or oil) for hours. Many machines simply won't have mouse support at all. Many will not have any typical external connectors. Indeed, units which go into dirty or wet environments certainly won't have standard external connectors of any kind. Think boats and factories. Internal battery packs with custom hot-fit replacements, buttons encased in 4mm of clear plastic, screens viewable only through protective mesh / filters.


4. Restricted connectivity - if the task doesn't need networking, no networking hardware is fitted. If the task doesn't need USB, no USB hardware is fitted. If the task doesn't need serial connections, there will probably be an internal serial connector but also a Warranty void if removed sticker. Don't expect an RS232 inside the case either, this will be a flat cable connector which you'll need to attach to a breakout board which correctly connects the cable wires to the RS232 port pins. That mapping is not standardised (why would it? only service engineers are approved to use it.)


5. Constrained user data - the task is in complete control and determines what the user can view, store and access. Storage can be expensive and a power drain, so if the task doesn't need Gb of storage, don't fit the machine with Gb of storage. Profit.

So what are these mysterious single-use computers running Emdebian? It's hard to tell because the task has no particular reason to tell the user anything about the OS. Perhaps a different way to phrase the same question would be: Why use a general purpose OS for a special purpose computer?.

• Single task does not mean single process - doing one thing can involve doing a couple of different things behind the scenes, so a multi-tasking kernel and userspace is extremely useful in providing a responsive machine without wasting money on unnecessarily powerful hardware. Multithreading support is also valuable.


• Software reuse makes good business sense - why write a single-usage operating system when the device needs a multi-tasking OS anyway and suitable ones already exist?


• Minimal software - no point packaging Xorg or GNOME when the user interface is a tiny QVGA framebuffer and the device only has 128Mb of RAM. By all means get the core system (cairo, pango, Qt, gettext, dpkg) from Emdebian but the actual code which performs the task of the device will generally be bespoke and, yes, that generally means proprietary, closed source, utterly non-free. This is where GNU/Linux wins over iOS and Windows - the graphical software is trivially separated from the core software and tested as such. If your device has only monochrome text output (and plenty of those still exist), what possible reason is there to use a graphical toolkit? Use the multi-tasking support of the OS to handle inter-process communication and understand the licensing - job done. Again, these devices have deliberately limited storage capacity, the smaller the OS, the lower the cost of the device, within certain constraints.


• Debugging compatibility - this is the big one. It's hard debugging the task software on device with the differences in architecture and connectivity. Why not use the same packages on the same OS on the development machines as on the devices? All the power and all the screen resources to properly investigate bugs, simple way to provide an emulator for translation support and other activities (like user interface training). There will always be bugs which have to be debugged on device - timing issues, hardware issues - but why not make at least a proportion of the likely bugs easier to fix by using binary compatible libraries on both the big desktop machines and the small devices?

This is why Emdebian Grip is popular for these machines - because Emdebian Grip is binary compatible with the equivalent Debian suite and when a bug appears in the high level user interface, it is much easier to debug that on the desktop than on device. Debian stable is a fantastic OS for commercial development - the stability of the OS makes detection of interface bugs much easier. It is rare that developers have to investigate whether bugs in their UI come down to a bug in the underlying OS. That saves time.

The machines themselves? I'm sure others can come up with other examples but these are some which come to my mind (no particular order):

• Control interfaces - solar power controllers, robot controllers - anywhere that a low power board can monitor responses from other machines and do something intelligent about reported errors. Temperature limit responses, pressure limit responses, encoding all of those in assembly or VHDL is hard, so use a system which provides for more creative result handling.


• Electric car charging points - very simple user interface, single task which doesn't complicate things by expecting the user to tap on something to start the main application - just process the card details, charge the customer and provide power.


• Similarlyelectronic point of sale devices - EPOS. The staff on the shop floor don't want to be waiting for an X server to start up and then using a menu. The device starts up and runs one task (checking barcodes, printing labels, counting stock), if the task is shutdown, the machine shuts down.


• Communication aids - my area, a machine which presents a simple UI on non-standard framebuffer hardware, lots of audio output but little other connectivity. Resilience is very important, so solid state is vital but why provide more solid state storage than the device can actually needs?

Anywhere where the device simply needs to DoTheRightThing in a variety of unpredictable circumstances, you're going to need a general purpose OS to gather the data and produce the right result. Anywhere where the device has only a single task, you're going to want to not provide access to the rest of the system. There's no point providing "general purpose access" when the device doesn't have "general purpose hardware". There's no point fitting general purpose hardware if the device does not use it. That is a waste of money, a waste of resources and causes unnecessary delays if one component or other becomes unobtainable or changes behaviour. Limit your exposure to hardware bugs and get the product out to the user more quickly and more reliably, everyone is happy. Fit non-standard hardware and you can fit custom hardware which better matches the profile of the device usage - why use standard speakers capable of CD quality across a vast frequency range when the device only makes very very loud alert noises which can be done at lower sample rates and with narrow range, high amplitude, speakers.

There are all sorts of estimates for the number of computers now in the average Western home. It's worth noting that the vast majority of those computers are not PCs or laptops or even game consoles and routers - all instances of general purpose machines with general purpose access / connectivity. A lot of the computers in your home are embedded in machines like white goods, media controllers (set top boxes and the like). Some of these will still use low level firmware written entirely in assembly or COBOL. More complex ones already have a general purpose OS inside yet constrain that OS with a simple, user-friendly interface which is tailored to the hardware actually fitted. It might be cool to connect to your set top box over Bluetooth but really, is that actually going to sell more units? Only if there are other high-end services written for the device which the average customer won't want to see pushing up the price of the base unit. Some machines (particularly in automotive uses) will need to be using Real Time operating systems and Safety Critical operating systems but even some of those are based on general purpose systems - just old versions which have been thoroughly tested.

Finally, consider that for a lot of these devices, the customer is not you. The customer is another business who then put the device into something else which is installed into a factory production line which produces something which goes into creating a consumer product you find in Tesco or on Amazon or bundled in with another service like your TV/broadband contract. There is absolutely no reason for these devices to provide general purpose computing to you, even if the device itself is part of something else which can provide such services.

OK, this one is meant for Planet Debian...

One of many, many changes in the latest lintian is vendor profiles and, thanks to a heads-up by Niels Thykier, Emdebian will have working profile support in the next upload of emdebian-grip. (The only reason it's not already in Debian is my own fault for not uploading when I thought I had the time to upload.)

$ lintian --profile emdebian-grip drivel_3.0.2-1em1_amd64.deb 

$ lintian --profile debian drivel_3.0.2-1em1_amd64.deb 

E: drivel: debian-changelog-file-missing

E: drivel: copyright-file-compressed

W: drivel: copyright-without-copyright-notice

E: drivel: description-contains-invalid-control-statement

W: drivel: binary-without-manpage usr/bin/drivel

So the em1 version implements Emdebian Policy for Emdebian Grip. Clean for Emdebian Grip, just as the Debian package is clean prior to the changes.

I expect this to dramatically improve the processing of Emdebian packages, both for Grip and for the cross-built flavour, Crush, once that actually starts up.

Thanks to the lintian team for this support. Now if there was some way of backporting this version of lintian to Squeeze, I could also use this at work to suppress really annoying lintian warnings about non-standard suite names. (The whole point of using a non-standard suite name is to keep our stuff separate from the normal Debian/Emdebian stuff for licensing reasons etc.) Update: of course, I didn't check the PTS for lintian before writing that, so hence didn't notice that the backport already exists! Thanks again to Niels for the prompt. I've now got another package to create for work. Update2: Thanks to Joerg Jaspert for the tip that all lintian versions get backported directly from unstable as an exception on ~bpo. The work package is ready, so this is going to make things a lot easier when building stuff on stable.

In other news, the same version of emdebian-grip will include support for integrating Emdebian Grip into Debian itself. This too will use vendor-specific support, this time an internal vendor name which just needs to work on the "buildd".

(It's not quite a buildd, Emdebian Grip doesn't build anything, it's all post-processing. It's just that the processing of Debian packages for Emdebian Grip will look a bit like having a second buildd working on the packages uploaded by the existing buildd. The process itself is still developing...)

Multistrap runtime message translations need updating but the manpages aren't being done this time around. More changes are likely before those get done.Current runtime translation status:

language        translated     fuzzy     untranslated

-----------------------------------------------------

  da               103           4             4

  fr                54          17            40

  pt                54          17            40

  vi                54          17            40

http://lists.debian.org/debian-i18n/2011/08/msg00105.html
Check with the relevant debian-i18n team for your language, this is just a prompter in case people miss the mailing list post.Update: Hmm, that went to the wrong blog. It got tagged i18n but was meant for the i18n blog. Ah well, doesn't hurt for Planet Debian to see what is going on elsewhere....

Just been testing the upcoming lintian 2.5.2 vendor-profile branch for operations with packages processed by emdebian-grip, both for the emdebian-grip and the emdebian-baked vendors.

The good news is that instead of the problematic support from Lenny, lintian in Wheezy will have support for testing Emdebian packages using Emdebian Policy. All Debian tags are up for grabs, no more exceptions for checks which couldn't be disabled before (like the forced removal of manpages).

Also been able to work out how to sort out lintian checks for Emdebian Crush including adding the extra tags which haven't seen use since Lenny.

So that's outline lintian support for Grip, Baked and Crush. Thanks to Niels Thykier for the lintian support.

This is a follow-up on TDebs with some detail of how existing packages can be adapted to support TDebs.

$ cat debian/package-tdeb.tdeb

[gettextdir] po
[gettextname] package
[po4apodir] doc/po
[po4amandir] doc/package/man/
[po4acommand] po4a-build


What's happening then? Well, the first thing to take into account is that a lot of the values for these settings will be dictated by upstream, which is why it is necessary for maintainers to add this information as a support file in debian/. I tried determining all this information automatically but the script got far too long and still was far from complete.

• gettextdir - usually po but some upstream packages can support multiple po generation, so this allows for those.
• gettextname - the hardest thing to identify reliably, this is the name of the files to be installed in /usr/share/locale/lang/LC_MESSAGES/ and the name of the of the POT file.
• po4apodir - po4a is for documentation translation support, which is more variable, so a po4acommand field is available too.

Other changes
The (currently unsupported in Debian) XC-Package-Type: tdeb option is used in debian/control to mark a new or existing package as a TDeb. To use an existing package, it must comply with the rules for a TDeb including that it must be Architecture: all. The other rules centre around build issues. If any of the files in the existing package would require execution of any part of the normal build process of the package, these would have to be moved out of the package before that package could be a TDeb. The reason is that TDeb generation by translators needs to not require a full build environment for every individual package and must not risk modifying package contents in ways which are related to the build environment. So, unchanged images and other architecture-independent files are OK, any files which need build-dependencies are a problem. I don't know how many packages there are out there with such files. If you have a -data or -common package which contains translated data and that package also includes architecture-independent files, I'd be interested in knowing the name of the packages involved. If those packages also include files which are generated or modified within the package build, I'll be particularly interested in knowing about those source packages.
debconf
The most common use of TDebs during a release cycle is probably going to be debconf template updates by Christian and these are handled without needing a listing in the .tdeb file.
Other formats
I'm looking at QtLinguist support and it should be fairly straightforward using the .tdeb file arrangement.

Once that's done (in a branch, please - these can't be uploaded yet), the package can be tested with the soon-to-be-uploaded emdebian-tdeb package. The old content has been moved into the emdebian-grip-server package and the dependencies of the old version stripped back. The package contains two scripts dpkg-gentdeb and dh_gentdeb which I hope to get included into the respective packages in time for Wheezy. The idea will be that build systems (dh7, CDBS, debhelper-plain etc.) includes a call to the relevant script. (dh_ is just a wrapper around dpkg- in this case). This would allow maintainers to create the first TDeb, get that through NEW and then the fun starts. Once the translation mechanism is set up, I would like a nominated person (likely to be Christian if he agrees) to co-ordinate translation updates for particular packages to allow for a single upload including updates for many translations. This would be package_version+t1_all.tdeb and an appropriate .diff.gz or debian.tar.gz. No binary upload, no impact on testing migrations.

This is mostly theory right now but the scripts do exist in Emdebian SVN.

Still more testing to do but I hope to upload these scripts to unstable in the next few days.

Haven't been in my new home that long and through a long chain of contacts, my neighbour was finally able to contact me. (Just goes to show that having Debian friends nearby who like board games turns out to make some things JustWork.)
So, when I got the message and got home the flat was fine - just with no electrical power. Murphy's Law ensured that my laptop was also low on power, as was my mobile phone and my landline is cordless and the router was, naturally, not working. My communication options were suddenly rather limited.

The 50yr old wiring in this block finally surrendered the magic smoke and caused a fire downstairs (mostly melted insulation) before it disconnected. I got home around 1pm, electricians to fix the problem arrived about 5pm and haven't finished quite yet. (It's now 12:11am). A relatively large hole in the lawn was dug (a hard task in itself seeing as this area is officially in a drought and the ground is like iron), two junction boxes rebuilt, new connection made from downstairs to upstairs, the work just went on and on.

I'll get some accurate details when I manage to speak to my brother - I do a little bit of hardware but I deal in 1W or a few hundred mA, when a 80A cable melts I'm just a bit out of my depth. I've not seen a fuse that size since I left school.

Thanks to those Debian and non-Debian people who helped me actually contact the relevant people today. I was due to get so many things done today, instead I got through the worry to end up incredibly bored - it turns out to be surprisingly difficult to find things to do when there is no mains power, all the batteries in mobile devices are flat and it's too dark to read.

Just added a TDeb test build branch for multistrap to test out the changes in the next version of the emdebian-tdeb binary package - specifically:

Move em_installtdeb into the emdebian-grip-server package so that the emdebian-tdeb package can be slimmed down to only contain what will become useful for other maintainers to use in their debian/rules files and for translators when the time comes to implement DEP-4. CDBS rules / patches to follow... bug reports against dpkg and debhelper to follow ...

DEP-4 itself is being restarted and refreshed but with some problems on alioth currently, I'm going to (try and) keep the document up to date via SGML and people.debian.org.

The changes are now in Emdebian SVN and I'm starting testing with my own packages first. Multistrap for PO and po4a-build testing, dpkg-cross for debconf testing, some others for testing with build systems other than CDBS, then the discussions will restart on debian-devel and I'll upload the TDeb support scripts to unstable.

There are a variety of things which need to happen before these scripts become useful, including:

• dpkg support for XC-Package-Type: tdeb
• debhelper support for dh_gentdeb,
• inevitable bug fixing in emdebian-tdeb

Why is the package called emdebian-tdeb? Simple - that's where the scripts have lived until now and the hope is that dpkg-gentdeb can migrate into dpkg-dev and dh_gentdeb into debhelper - eventually.

By all means play with the scripts and follow the example multistrap branch above to see what kind of changes might be needed in your own packages. I'll post again when I've worked out the changes needed in packages like dpkg-cross which only need TDebs for debconf support. (This is the easiest mode of TDeb usage but it's also the most useful during a release cycle - maintainers make a single change and then a nominated i18n boss-person - take a guess who - can update the all your debconf translations in one upload without a binary build - eventually possibly not even needing any bug reports, just a simple email advance warning.

What I've got to work on still is how the generation of an updated TDeb creates a new debian diff / debian.tar.gz to accompany the upload. For that I need XC-Package-Type: tdeb support in dpkg....

Sample output from the viewpoint of a translator updating a package already converted to support a TDeb:

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Set the changelog message to version 2.1.15+t0 first, closing any relevant bugs!

 dch -v 2.1.15+t0 

neil@sylvester:tdeb-test$ dch -v 2.1.15+t0 TDeb test

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Building TDeb update: 2.1.15+t0

 (192 entries)

Discard doc/pod/1/da/multistrap (65 of 177 strings; only 36.72% translated; need 50%).

Discard doc/pod/1/da/device-table.pl (5 of 19 strings; only 26.31% translated; need 50%).

Processing untranslated files for pod/multistrap (1) . . .

Processing untranslated files for device-table.pl (1) . . .

Processing de translations for pod/multistrap (1). . .

Processing de translations for device-table.pl (1). . .

Processing fr translations for pod/multistrap (1). . .

Processing fr translations for device-table.pl (1). . .

Processing pt translations for pod/multistrap (1). . .

Processing pt translations for device-table.pl (1). . .

dpkg-gencontrol -pmultistrap-tdeb -Pdebian/multistrap-tdeb -cdebian/control

dpkg --build debian/multistrap-tdeb ../multistrap-tdeb_2.1.15+t0_all.tdeb 

dpkg-deb: building package  multistrap-tdeb' in  ../multistrap-tdeb_2.1.15+t0_all.tdeb'.

neil@sylvester:tdeb-test$ dpkg -c ../multistrap-tdeb_2.1.15+t0_all.tdeb

drwxr-xr-x root/root         0 2011-06-08 21:06 ./

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/

-rw-r--r-- root/root      6427 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/

-rw-r--r-- root/root      6963 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/

-rw-r--r-- root/root      6789 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/

-rw-r--r-- root/root     16311 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/man1/

-rw-r--r-- root/root     33963 2011-06-08 21:06 ./usr/share/man/pt/man1/multistrap.1

-rw-r--r-- root/root      4471 2011-06-08 21:06 ./usr/share/man/pt/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/man1/

-rw-r--r-- root/root     33969 2011-06-08 21:06 ./usr/share/man/fr/man1/multistrap.1

-rw-r--r-- root/root      4708 2011-06-08 21:06 ./usr/share/man/fr/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/man1/

I'm also going to DebConf11



On the RoadTrip! all the way hrough France, Belgium, Netherlands, Germany, Austria, Slovenia, Croatia, Bosnia-Herzegovina (Banja Luka) in an MX5.

I've got a lot of things to talk to people about @ DebConf this year... you won't be able to tell if I'm just buying you a beer or trying to badger you about your packages!! Just note that TDebs have been already agreed (in terms of how TDebs work in the archive) with ftp-master at a previous meeting in Extremadura and I'm being badgered by a Release Manager and an ex-DPL to get TDebs implemented real soon now, so it is going to happen and hopefully in time for Wheezy - it's just a matter of fixing the bugs. The quicker everyone has a look at the new scripts (which have been completed re-written and immensely simplified since I first tried a dumb conversion of em_installtdeb) and the likely changes needed in packages, the quicker I can get the bugs out of the scripts.

More documentation to follow, I'll be updating the SGML whenever practical and the actual DEP just as soon as I get commit access back.

I'm experimenting with building Qt Embedded for armel using Emdebian toolchains and Debian packaging/patches. Initially, I've just "got it to build" with a few too many things nobbled and disabled - the results (using the package from Squeeze) are in Emdebian SVN - and the next task is to enable the missing bits and get closer to the standard Qt4-X11 binaries. Certain packages will simply not exist, even when finished, but it's been fun working out how to create a qmake.conf to map the Emdebian toolchain to what Qt expects from toolchains like CodeSourcery.

If it continues to work, it may be worth pushing upstream - but it may be better to wait until Multi-Arch supports cross-building, I'd only have to submit a different qmake.conf with updated paths otherwise.

I've also got a basic qmake.conf to help Qt applications cross-build using the Emdebian toolchains. This also needs updating once we finally get Multi-Arch-Cross.

The way I see this working is that the Qt Embedded packages would have to kept entirely separate from the Debian Qt4-X11 binaries from the KDE/Qt team because they use the same package names. That's relatively simple if the embedded packages are kept for cross-building only, either as -armel-cross packages generated by dpkg-cross or (eventually) as Multi-Arch packages. What won't work is having Qt-X11 and Qt-Embedded installed on the same architecture, without using a chroot or similar.

Initially, I hoped to keep the changes small enough that the Debian package could include the tweaks in a conditional part of debian/rules via a DEB_BUILD_OPTION. The current diff is a little too awkward (mainly in the .install files) but that's still worth keeping as a goal.

No warranty, created in the hope it's useful etc. etc., nothing to say it'll build on your system, no support for anything except the Debian armel port and only tested with the Emdebian toolchains from Lenny, not coming to a distribution near you anytime soon, don't blame me if it messes up your entire Qt-X11 installation on your desktop.... yada, yada.

It's just a bit of tinkering really, although it would be more fun if Qt didn't take quite so many hours to build each time I want to test a change....

I've been nagged for a while (by Wookey mainly) about the unhelpfulness of dpkg-checkbuilddeps when it outputs the versions and alternatives alongside the package names which are missing, making it harder to pass the list to the package manager. apt-get build-dep isn't particular helpful either - it doesn't look at the modified package at all.

Of course, once the output is in a suitable format, a new script might as well make it possible to simply pass that output to said package manager. Once it can do that, it can then pass the output to the cross-dependency tools, like xapt.

So, I've refactored the embuilddeps script in the xapt package to do just this.

It's gained a few features in the process:

1. Support for Build-Conflicts resolution


2. Support for virtual packages, swapping the virtual for the first package to provide it (borrowed some code from Dpkg::Deps for that one).


3. Support for Build-Depends alternatives (currently using the buildd default of "first alternative gets first chance")


4. Reads data from debian/control, not the apt cache - to help with the package you're building instead of the one you've already uploaded.


5. Handles cross dependencies (which are always assumed to not currently be installed) and native dependencies. This support is transitory until such time as enough packages are Multi-Arch compatible that Cross-Multi-Arch becomes trivial.


6. Support for being used as a build-dependency resolver in pbuilder, including cross-architecture dependencies with pdebuild-cross.


7. Can locate a debian/control file in a specified directory without needing to be called from that directory


8. Checks your apt-cache policy to see if the required version of a package is available from your current apt sources. Fails completely if not. (The pdebuild-cross usage will need that to be extended a touch to look at the apt-cache policy from within the chroot.)


9. Hector Oron has also been asking me to get embuilddeps working with sbuild, so I'm working on that feature too.


10. verbose and quiet support (so use -q inside other scripts)


11. most output is already translated - more translations are welcome, especially for the documentation, but hold on until this version has actually been uploaded.

More testing is needed, particularly that the extensive refactoring hasn't broken the pbuilder resolution support and then looking at what still needs to be done for sbuild support. The new script is in Emdebian SVN.

The first-choice method for virtuals and alternatives may well bear extension to explicit management via command-line options. I'm unsure yet whether it needs to be a configuration file setting. It could simply be a recursive - try one, move on - model.

I was going to make this a comment against Ritesh Raj Sarraf's post about patents and pharmaceuticals but the comment got way too long.

The basic problem is that patents on pharmaceuticals cannot be directly compared to patents on software and the explanation gets a bit involved. It's worse than apples and oranges, it's more like comparing an algorithm to a piece of DNA.

Patented pharmaceuticals must declare the precise chemical formula of the molecule (and a whole lot else besides) before the molecule can be brought to market but the company holding the patent is legally prevented from protecting themselves against slightly different molecules which are blatantly based on the protected molecule. All modification results in a new patentable product, legally separated from the original.

Therefore, the first company to patent a molecule from a new class is instantly joined in the field by other companies who are (obviously) watching the research news channels very carefully. (In their shoes, you would do the same or you go bust.) These companies simply add a flourine ion or change a hydrogen to a hydroxl group or any other number of minor, apparently inconsequential, changes. Changes which, in software, would be deemed a derivative work and would be roughly equivalent to changing a single local variable from a 16bit integer to a 32bit integer in a single function in a single file in the entire codebase. i.e. a trivial bug fix or even a typo.

A molecule with a couple of hundred atoms can have a change affecting one atom and be a completely new patentable item without any risk of the other company being sued for patent infringement, plagiarism, copyright violation (there is no copyright) or any other barrier. It's common to find that molecule foo is joined on the market by a desoxyfoo and a flourofoo etc. with a chlorofoo just around the corner, within months of the class-leader being launched. It can't be compared to software - effectively, every new release gets a new patent which covers the entirety of everything contained in that release, even if 99.999999999% of it is precisely the same as is covered under other several other patents held by extremely litigious competitors.

Modification is simply not prohibited - copying without making any changes whatsoever to the active molecule is prohibited. Changes to the inactive ingredients will be prosecuted - changes to the active ingredient will not. Comparing this with software is likely to drive you insane.

For example, the mere process of packaging an upstream release for a distribution would be patent infringement in pharmaceutical terms - UNLESS you deliberately patch the original source to make an utterly trivial and apparently pointless change. At that point, the upstream completely disown your entire release and you would have to fix every bug yourself - without the original upstream even telling you whether they fixed the same bug themselves, because they aren't ABLE to modify the upstream code without starting a whole new project and they won't tell you why or how they changed things. There is no such thing as an alpha-release of a molecule. Every release is final and no subsequent modification is possible - unless it only affects the inactive ingredients, e.g. by adding a slow release coating. These changes can affect the way that the molecule acts on the test subject / patient but must not change the active ingredient itself in any identifiable way. So the upstream can make a new wrapper (new packaging) but nobody else is allowed to do so until the patent expires. Once the patent expires, every one and their dog is allowed to make identical copies of the active ingredient in their own inactive packaging and these are called generics. Generics still need testing to ensure that the active ingredient truly is the same and that the generic behaves in the same way as the original but this process is cheaper than making a change to the active molecule.

A changed active molecule is an entirely new substance, it gets a new patent and it needs to go through largely the same amount of testing as the patented original but the new company still gets a head start on what the molecule is likely to do and what side-effects (by now noticeable with the class-leader product which is in large scale trials or even on the market) would be harmful to the future usefulness of their new, derivative, molecule. The new company simply jumps onto the bandwagon shouting "I want a piece of that action!" and there is absolutely nothing the original company can do about it, except try to show that their original molecule is better than the new competitors and to try and build a substantial market share before everyone switches to the new derivative. (Prescribers are human and tend therefore to be lazy, so unless there's a reason to change, the class leader will still have substantial share even after several derivatives exist.)

It's an arms race - each company tries to create as many of these potential "me-too" variants as possible in-house, put as many as can be (financially) supported through trials, keep pursuing those which don't have prohibitive side-effects / problems in tests and hope that, at the end, one of their versions will actually turn out to have better effectiveness or fewer side-effects. If not, they just have to market one as "as-effective-and-no-more-harmful-but-CHEAPER-than" the class leader. The majority of "me-too" molecules come under this category - even if the company concerned would try to point to infinitesimal differences in trial data to pretend otherwise. All this with the knowledge that the very hour that the patent expires, a dozen generic manufacturers will flood the market with copies which do not need to recover the massive costs of the original research and are therefore massively cheaper.

How much cheaper? patented molecules may cost 30 for 28 doses on Monday and one generic may cost 3p for 500, another may cost 40p for 10,000 on Tuesday, the day after the patent expiry. Generic houses only need to cover the actual costs of manufacture, not the costs of the original patent etc. and by the time the patent expires, the efforts of the patent holder to generate market share mean that economies of scale become evident. The absolute cheapest isn't necessarily the one who gets the contract either, these things all have expiry dates and all 10,000 have to be sold / supplied from a single location within that date to actually deliver the full savings. So then you get satellite generics who buy in quantities of a few million and pack down into 56 or less so that the total purchased quantity can sit on many shelves instead of just one. It's the same tablet in the end, with the same markings too. All that differs is the marking on the foil and the colour of the cardboard. (Oh and the same foil and colour cardboard can contain tablets with different markings from different manufacturers from one batch to the next, all within the branding of the same repackaging company.)

The original patent-holding company also has an interest in generating their own "me-too" derivatives, sometimes marketed under the name of a company which turns out to be solely owned by the parent of the original company. It can get horribly recursive.
Sometimes, the derivative from the sibling company hits the market before the "true" competitor from a different company - simply because all companies try to have many molecules in development at any one time (because most changed molecules fail in testing) and sometimes they get lucky and come up with two v.similar molecules and have to do something to justify the cost of developing both. That can turn out to be a poisoned chalice rather than two golden geese.

Sometimes, the company fails to get enough variants through testing and the company then gets bought out by a rival - who then gains their research and continues experimenting with other derivative molecules based on the ones already tested and dismissed. The limiting factor is the money.

At this point, I must now declare my cards. I used to be a pharmacist and although I am still entitled to call myself the holder of a Batchelor of Sciences degree in Pharmaceutical Sciences I am most definitely no longer a pharmacist. I therefore defer to my still-registered colleagues in case I've messed up any of the detail here. The above cannot be declared as the opinion of a pharmacist. I am an ex-pharmacist who voluntarily chose to resign his registration to take up full time work as a software developer rather than pay the exorbitant costs of maintaining such registration and all the "proof-of-competency" requirements which such registration requires.

Finally, before you ask, I am very happy to be an ex-pharmacist - my erstwhile colleagues have my ongoing sympathy but no matter how much some of them may beg, they all know that I will not be rejoining them on that side of the dispensary bench if I've got any choice in the matter.

Software is just better. It's all just recycled electrons.

At the Emdebian ARM sprint, cross-building experiments on a Multi-Arch base are going fairly well. It is looking like the hacks in dpkg-cross may finally be avoidable, possibly before Wheezy gets released. Elsewhere, debhelper has been updated to allow dh_strip and other tools to work directly with the binutils package from the cross-building toolchain and not to need binutils-multiarch any more. dpkg-cross has been updated to only Suggest binutils-multiarch, which makes room for more architectures to be covered by binutils-multiarch (which, therefore, will be getting quite a lot bigger quite soon).

Cross-building in Debian is therefore entering a period of transition and the old ways of dpkg-cross - and the tools it has spawned like apt-cross, xapt, pdebuild-cross and others - will be gradually side-lined and finally rendered obsolete. Like all transitions, there will be breakage, there will be pain, there will be things which don't cross-build now and which have no prospect of being fixed until the transition is deeply entrenched. There are packages which used to cross-build and which will stop cross-building and, again, won't be fixable for months. Sadly, Squeeze released with cross-building breakage too, due to changes within apt during the release freeze. A Lenny chroot is possibly the best place to do cross-building for now.

This is a major transition. It WILL break things. Badly and often.
What's more, just because we decide to implement stuff using one method now does not mean that the same method will even exist in a month or two.

In other words, if you've got a working cross-build chroot or installation currently and you absolutely need it to continue working leave it alone.

Don't go changing real packages to use the changes we're trying out!

If you enjoy fixing stuff, don't mind pain and fancy risking your system as I've been doing (unlinking /etc/, deleting /lib64 on amd64 or forcing package installation such that no shared libraries are accessible any longer) then you are:

1. insane
2. welcome to join the work

Check out the current state of things via the #emdebian channel on oftc.net and the very risky Emdebian multiarch SVN experiments along with the even more risky Emdebian Multiarch Mirror, courtesy of Steve McIntyre and Phil Hands.

The README in SVN is very clear - DON'T INSTALL THESE OUTSIDE A CHROOT and even if you do, don't come crying to me when it breaks your entire system (even when used inside a chroot).

No warranty, no guarantees, no promises, none of this is fit for any purpose whatsoever and we'll say when we finally have something which might actually be useful.

Sometimes, free software isn't better than proprietary, it's true - and one of the principal reasons is that the majority of free software does not use the full power of the freedom of the software. Far too many free software projects are single-developer projects. Many single-developer projects at SourceForge or Savannah and elsewhere have a single maintainer for the distribution providing the packages too and some (including nearly all of my own) have one person doing both jobs. In other words, there is no collaboration upstream or in packaging, so there is little or no benefit to the code of being free software...

It begs the question of what happens when the omnipresent developer-under-a-bus risk actually bites.

When comparing free software and proprietary, considering end-of-life effects can be very illuminating, especially when considering the interests of third-parties who come to rely upon the output of the project. When a proprietary software producer declares a software product to be end-of-life (whether due to collapse/purchase of the company or some other restructuring) third parties are left high and dry. In effect, all proprietary software is directly equivalent to a single developer writing free software. The more important the software, the worse this gets because at least if the single free software developer does disappear, the third party can try and pick up the pieces.

The bigger problem for free software is the common failure to actually collaborate. This has been my main upstream bug bear for a long time now. The model must change. New contributors must be dissuaded from writing new code just because they prefer one language over another. Distributions need to change their guidelines for new developers to actively discourage new packagers from starting with new upstream code. We are in danger of undermining the main appeal of free software by not stamping harder on the NotInventedHere (NIH) syndrome. NIH is pernicious, NIH is dangerous and there is even an argument for considering NIH as an anti-feature.
New is considered harmful
New is not necessarily a good idea, new can be positively harmful to the interests of the wider software community. New promotes reinventing the wheel. It's another incidence of "Just because we can, does not mean we should."

If free software advocates neglect to counteract the poison of NIH, then free software will lose the argument by losing the fundamental merit of free software. A freedom which is not utilised is akin to not having that freedom at all. Yes, someone can pick up a free software project after the single developer abandons it but, in practise, what actually happens is that someone else comes along whilst the single developer is struggling along alone and decides to fall prey to NIH simply because the original is written in C and their preferred language is Python or Ruby or Haskell or whatever.

The "choice" argument is simply invalid - providing another implementation of program foo in a different language is just a way of reinventing the bugs already fixed in foo in new ways in a new language - and then adding some more which are unique to that language. Yes, the new developer might argue that the new code is more active but for how long? Long enough to become just as stable as the abandoned code? What benefit is that? In a few years time we will have two abandoned codebases in two different languages written by two different developers who never collaborated on the actual problem both of them were trying to solve independently. Lunacy.

The dilemma for distributions like Debian is that the list of Debian Packages that Need Lovin' is a burden to Debian during a release freeze yet provides an ideal launchpad for new developers to refresh stale code. I've long thought that Debian needs to be more strict on removing such packages, yet at the same time I cannot help but feel that this tends to encourage more NIH behaviour.

It's a common mantra amongst free software developers that many eyes make all bugs shallow. The problem for free software is that outside certain key teams, there are simply too few eyes and the community is not doing enough to shine a light on existing code before dancing to the sound of the NIH drum.

Far too much free software is at risk from that omnipresent bus called "RealLife" and this makes far too much free software little better than proprietary software. Pandering to the fashions of NIH only makes things worse.

This isn't a technical problem that can be solved with a new cool tool (which itself is subject to the NIH poison), it is a social problem and, sadly, the free software community has a history of failing to tackle purely social problems successfully.

There is a small role for existing technical solutions to make it easier to spot NIH tendencies, including sites like SourceForge and Savannah having greater scrutiny about new projects and distributors like Debian being more averse to adding yet more ITP bugs (or closing them automatically unless something happens within a month). Fundamentally, it comes down to how new and existing members of the free software community decide to handle their own projects and bugs. The model of "do it this way because that's more fun" has got us so far, the challenge is to remove NIH tendencies without removing that fun.

A continuation of my intermittent series on Emdebian. This time covering how Emdebian changes component behaviourin Emdebian Grip.
Debian divides packages principally between those which comply with the DFSG (main), those which do not (non-free) and those which could but depend on those which do not (contrib). This leads to an enormous bias towards packages in main, which is good in terms of DFSG compliance but not so good for the size of the Packages files which every machine has to download to be able to install new stuff or upgrade existing stuff.
Emdebian is as concerned about the runtime space requirements of the system as much as the install time space requirements. Little point gaining 20Mb by removing stuff from packages if the next apt-get update adds 30Mb of cache data.
Therefore, Emdebian Grip sub-divides main (we don't have contrib or non-free packages at this time). This gives most users the smallest cache data size whilst allowing other users to add the extra components and get the full list of packages provided in Emdebian.
Alongside this division, the aim with emdebian-grip-server is to help others run secondary Emdebian Grip build machines which have a different range of packages. This allows one server to focus on XFCE and one to use other desktops or no desktops.
Components in Grip
Grip subdivides Debian main into main (~60%), dev (~30%), java, debug and doc components. The main emphasis, therefore, is that most Emdebian Grip machines will not be used to actually build other packages. I covered some of the theory on this step on the debian-embedded mailing list in 2009.
Component allocation
Packages are allocated to particular components by three main mechanisms:

1. Package name suffix - -dev packages into dev, -dbg packages into debug, -doc packages into doc.
2. Section names - devel goes into dev, java goes into java
3. Override files which are visible via the emdebian website.

Override files cover situations where a package is in a problematic Section (e.g. dbus is in Section: devel when it is almost impossible to have a netbook or graphical Debian installation without it). Once Squeeze is released, I might take up these overrides with ftpmaster to see if some rationale can be constructed to make things easier.
Sources
The use of components means that an Emdebian Grip device can choose a range of components in the apt sources line. Any permutation as long as main is preserved.

deb http://www.emdebian.org/grip squeeze main dev debug java doc

More on Filtering
I mentioned last time that Emdebian does not carry all packages available in Debian. As well as filtering the files contained within packages, Emdebian Grip filters the list of packages which are allowed into the repository for each server. This is why Emdebian Grip has under 3,000 packages to be released alongside Squeeze. (Emdebian Grip 1.0 based on Lenny had some 1,000 packages.)
Filtering the list of packages means that the maintainer of the server gets to choose their package set in a similar way to how tasksel can be used to select a functionally complete set of packages at installation time. (Indeed, Emdebian Grip provides some bespoke tasks which optimise the combination of tasksel and repository filtering.) Processing packages for Emdebian Grip takes a finite amount of time per package, per architecture and restricting the total number of packages in Grip has several advantages:

1. Further reductions in cache size - less files in the Packages file, less Packages data to download and cache.
2. Less processing time which makes it easier to maintain an Emdebian Grip server
3. Less data to mirror which makes it attractive for admins already running a full Debian mirror to consider squeezing in Emdebian Grip alongside.

Combining component changes and filters needs a little bit of careful handling in the server side code so that packages remain installable. Override files need to be adjusted manually, library transitions mean that once libfoo0 has been replaced by libfoo1, anything depending on libfoo1 is broken in Emdebian Grip until libfoo1 can be added to the repository (which is also a manual task). I'm glad that edos-debcheck is regaining a machine-parseable output format because this will add the chance to make at least some of these transition additions automatic. Other than these tasks, emdebian-grip-server is almost entirely automated and runs as a cron task creating verbose log files each run.
The server task runs edos-debcheck for each supported architecture and for each suite, carefully combining the various Packages files from the available components. As an alternative assessment, Debian Weather runs edos-debcheck over the Packages file for the main component only, for each suite and each architecture in Emdebian Grip. The combination of the two provides invaluable data to spot missing packages.
Equally, there are times when packages disappear from Debian. Currently, the automated scripts don't handle this aggressively but manual support scripts are available, usually for use before a release when the suites are changing less frequently.
I'll cover migrations between suites next time. In the meantime, if you want to prepare your own package set for Emdebian Grip, install emdebian-grip-server from experimental and file bugs to improve the documentation.
Thanks to those who took on the Herculean task of translating the emdebian-grip-server manpages into German and French - more translations are always welcome. POT file contained inside the source package.

Developers are not usually the right people to write documentation, but in an effort to encourage more Debian folk to consider Emdebian, I'm starting an intermittent series of blog posts to describe how Emdebian works and how it fits with Debian. Emdebian has a variety of ideas and experiments but the principle distribution, to be released alongside Debian Squeeze, is Emdebian Grip. This post, I'll cover the basic stuff. Feel free to let me know if there are particular issues you'd like covered. In particular, if the documentation on the Emdebian Grip website needs improving, let us know.
What's Emdebian Grip all about?
Simply a smaller Debian. Smaller packages, smaller downloads, smaller sets of packages, smaller installation sizes and smaller update sizes; yet always and completely binary compatible with Debian. Every backtrace from an Emdebian Grip device will match the backtrace on a Debian machine of the same architecture, package version etc. Packages can be mixed trivially (with some allowances for strict dependencies like -dbg packages). The name is a derivative of Squeeze - to make Debian smaller, we take a hold of it; Grip it.
Is it cross-building?
NO. Emdebian Grip is not recompiled (natively or cross), it is processed. Packages natively built in Debian are unpacked, files removed and repacked on the server before being included into the Emdebian repositories. dpkg and perl do all the work, not gcc.
What gets taken out?
Translations move out of the source packages and into TDebs (organised by locale) and compiled .mo files are then removed from the binary packages. Manpages and other documentation is lost entirely, copyright is compressed and changelogs are removed. None of the binary files are touched. The SHA256 sum of your /usr/bin/foo executable in Debian will be precisely the same in Emdebian, the same applies to libraries.
How is it done?
The emdebian-grip-server package in Debian processes the package and treats every architecture in the same way. (This allows Emdebian to carry unofficial ports like SH4, armhf etc.)
Why not filter stuff with dpkg?
The straight answer is that there usually isn't room to download the large package first in order to strip it on device. Also, filtering on device is slow. Stripping the package on the server means that the work is only done once. Every Emdebian device is saved the effort of filtering the files one machine at a time. Grip effectively does what dpkg filtering does, just it does it on the server, repacking the results into a new .deb. Instead of every device doing the task again and again, the server does it once.
Why is my pet package not included?
Emdebian restricts the number of packages which are included in the repositories (less than 10% of Debian packages will be included in Emdebian Grip 2.0 which is based on Debian 6.0 "squeeze") but provides tools which can be used (on device or on the desktop) to prepare any other package for installation on an Emdebian Grip device. There is no need for the machine preparing the package to be of the same architecture as the intended device because all processing is architecture-neutral.
Who decides which packages get included?
Me, basically. The merits of adding particular packages is usually discussed on the debian-embedded mailing list. Typical criteria (in rough order) include:

1. Subjectively suitable for an embedded device (so OpenOffice.org does not qualify)


2. most, if not all, dependencies already included in Grip


3. already available in Debian testing


4. not in a state of churn in Debian (rapid upload cycles, frequent library transitions etc.)
   
5. not particularly buggy in Debian

Can I convert Debian to Emdebian Grip
Yes - simply add Emdebian to your apt sources list and watch as your next upgrade releases tens of megabytes of space.
What are these em1 version suffixes?
Emdebian modifies Debian packages, albeit in an architecture-independent manner, by removing files. The resulting packages are therefore different to the originals, albeit containing compatible binaries. Hence, the Emdebian processing adds the em1 version suffix to show which version is installed. Adding the suffix also means that every Emdebian package is considered to be an upgrade compared to the equivalent Debian package, if both exist in your apt sources.
How is Emdebian Grip installed?
It is possible to use Debian Installer (we provide pre-seeding files to help this process) or create a simple tarball using multistrap if that is more suitable for your device.
What about Recommends: ?
Debian defaults to installing all packages listed as Recommends in the package metadata. Emdebian simply drops the entire Recommends field when processing the package. Suggests is also omitted. This dramatically shortens dependency chains and gives developers full control over which packages are installed. It is important here to consider the embedded device user interface. Recommends exists to support those users who need the extra parts of the package, the bells and whistles. Embedded devices strictly control which parts of the package is actually exposed to the user - there is no need for a menu or a desktop. Users can only access the functionality exposed by the device, so no bells and whistles - just the base system and whatever you choose to expose as part of the interface. Rather than require all Emdebian devices to turn off Recommends individually, Emdebian simply drops Recommends at the server and allows the developer to cherry-pick which packages to add.

More to follow . . .

There must be other organisations across the world which do a similar job but this is the local one for me and in lieu of actually getting to a Remembrance Day event this year (I'll be at a bug squashing event for Debian Squeeze), I'm using my blog, just this once, to express my own thanks to those who gave their lives that I may be free to do what I enjoy, writing code to make things just work.

Just in passing, if anyone wants to support my work in Debian and/or Emdebian, there is a simple and free way to do it. Send me some patches, especially for documentation, translations and examples.

I have more than enough stuff that I could be doing and I do hear from users who want more stuff done to suit their particular requirements. Sorry, but time is finite and whilst a "thank you" is always appreciated, it doesn't actually generate a 25 hour day. So please don't just tell me what you want or why the current stuff doesn't do what you want it to do. The source code is all just "out-there" and you know more about what you actually want than I ever could.

If any of my code doesn't quite do what you want, please don't moan about it or file bugs that just moan about it, work out why and how and fix it - get involved. That way, the code will develop even if I don't always have time to work on it.

I've been trying to work out how to handle (or whether to handle) the vestigial debconf values from emdebian-tools which was replaced in Debian some months ago. I tried to transfer the postrm script to libemdebian-tools-perl which itself is currently a transitional package. Turns out that when debconf tries to purge libemdebian-tools-perl, it doesn't purge the old emdebian-tools settings (it looks for libemdebian-tools-perl.templates instead of emdebian-tools.templates) - unless those were themselves setup by libemdebian-tools-perl. i.e. users with the original emdebian-tools setup will likely have debconf settings that are not purged by removing the package to which those settings should have migrated.

I have reconstructed a bare templates file locally and a simple script that can purge those values and it works on my system - I'm just not sure if this should be implemented in what is now merely a transitional package (libemdebian-tools-perl) which exists merely to support migrating to the current emdebian-crush package.

It's only three fields - single word values - and debconf settings are only a cache after all. Comments are still disabled on my blog but my email address isn't hard to find. If people really think it's worth writing code to "catch-up" with these redundant settings, I can do something after Squeeze. What I don't want to do is reintroduce debconf templates which are no longer used, merely to remove old settings left behind from the first migration.

So, lazyweb, what's the feeling? Is this worth doing anything about?

This took a bit of searching, so it's here for reference. I'm sure it'll catch out people who upgrade from Lenny to Squeeze as the initial presentation can be deeply mysterious and frustrating.

I keep my pbuilder stuff outside /var/, so I have a file /home/neil/.pbuilderrc and until recently, this worked fine. Naturally, pbuilder needs sudo to call it, so sudo pbuilder update was a routine command. Then it suddenly stopped working and it was mysterious, pbuilder was looking for /home/root/.pbuilderrc which was just weird. root/.pbuilderrc might make a little more sense, /home/root is just plain wrong.

First, blame pbuilder, no, not changed recently - certainly not since I last ran the command successfully. Hmm.

sudo then? Recently updated, aha, the changes listed in the PTS describes something being documented in NEWS.Debian relating to pbuilder - dig, dig, the answer (indirectly) was in the README. Need to add a command to user lines in sudoers:

, env_keep+="HOME"

Also, act on this guidance in sudo visudo:

# Uncomment to allow members of group sudo to not need a password

Even more nastily, sudo does still need a password (because I've set rootpw later) but this line is still required.

Now restart sudo sudo invoke-rc.d sudo restart which is horribly recursive. (Yes, I did mess up visudo at one point and have to use just plain su to get back access.)

Ho hum. It works, so why do I feel that I've done something bad?

(comments still disabled because of spammers - captchas simply don't work, neither does OpenID, so don't blame me. Those who know me already know how to contact me. The details aren't exactly hidden.)

Emdebian Grip 1.0.1 (based on Debian GNU/Linux 5.0.6) is now available.

Emdebian Grip is binary-compatible with Debian, providing smaller packages for use on embedded devices. Emdebian Grip selects a subset of Debian packages and removes documentation and other non-binary content without recompiling the source code. Currently, Emdebian Grip supports amd64, arm, armel, i386, mips, mipsel and powerpc in the stable distribution. ARM support will be dropped in the next stable release in favour of armel.

This is the first update of the stable distribution Emdebian Grip (based on Debian GNU/Linux 5.0), bringing Emdebian Grip up to date with Debian 5.0.6. This update mainly adds corrections for security problems to the stable release, along with a few adjustment to serious problems.

Please note that this update does not constitute a new version of Emdebian Grip 1.0 or Debian GNU/Linux 5.0 but only updates some of the packages included. Systems will upgrade to 1.0.1 via the Emdebian mirror after an installation.

For more details on the changes within Debian through 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5 and now 5.0.6, see the Debian news website.

As well as updates to packages which already existed in Emdebian Grip 1.0, the update includes many new packages, including apache2, aspell and variants, and matchbox.

e.g. 822 packages were released for armel in Emdebian 1.0; this update increases that number to 1,297.

In case anyone else hasn't found these tweaks:

termcapinfo xterm xterms xs rxvt ti@:te@

In ~/.screenrc gives you Shift-PageUp and Shift-PageDown control again, without resorting to Ctrl-A Esc, inside screen. (Best to do

$ cp /etc/screen.rc ~/.screenrc

as a starting point first, if not done already.)

Also:

/set scroll_page_count /2

/save

In irssi itself (easier than editing the config) gives you internal PageUp, PageDown control within the irssi window.

In each case, the manpage is so long and impenetrable that these may be obvious to those with a special knowledge of terminals but mere mortals like me can't find it in / understand the docs.